Weird, I interpreted that issue as being about something completely different - that is, what happens when there is a $schema keyword lower down in the document (that is different than the root level $schema). Bundling seems somewhat orthogonal to that concern.

Why do the referenced resources have to have absolute URI identifiers in order to be bundled? In my (admittedly simple) implementation of bundling in a json-schema-using application, which uses $refs of the form "$ref": "common_defs.json#/definitions/Foo", I just move the definition subschema over into the main document and only rewrite the definition name if it conflicts with another name -- so there are no $ids in use anywhere.

@karenetheridge What if common_defs.json#/definitions/Foo has a local reference to another definition in common_defs.json? The reference would now point to definitions in the wrong document. Although simple transculsion works in many cases, the only way it always work is if the schema being referenced has an $id.

@jdesrosiers All the definitions being moved are also scanned for embedded $refs and those schemas moved across as well, and so on recursively until all definitions are moved (with $refs pointing to them rewritten as needed). It's not very hard at all as long as there are no definition names that collide, and in that case they just get a _1 or somesuch appended to them.

Just because there may be edge cases some of the time that require an $id (or would make the bundling process easier) is no reason to require an $id in all cases.

@karenetheridge

Sorry, what I wrote doesn't make sense. Let me try again. You're right, you can bundle schemas without $ids, but it means you need to recursively rewrite all the references.

Ideally, whether a schema is bundled or not, you should get the same output. When you rewrite references, your keywordLocation and absoluteKeywordLocation values will be different. A bundle should just be a convenient delivery mechanism, it shouldn't create a new schema. I, for one, want to be able to maintain traceability to where the referenced schema originated.

Also, when you need to embed a schema of a different draft, you need to include $schema, which means you need to have an $id. There's no way around that one.

I boradly agree with @jdesrosiers regarding tracability. It should be EASY for people to work out which of the schemas they have bundled, back to the original files. The FHIR bundled schema is comprised of a LOT of schemas. A LOT.

Also, when you need to embed a schema of a different draft, you need to include $schema, which means you need to have an $id. There's no way around that one.

I'm not sure I follow. $schema is required, but $id isn't specifically required in 2019-09 or indeed in current main branch iirc. How did you arrive at this conclusion?

@Relequestual I didn't mean anything controversial with that statement. I just mean that without $id you can't embed a schema that is a different version as the referring schema if they are not using the same draft. Quick example ...

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "type": "object",
  "properties": {
    "foo": { "$ref": "./schema/foo#/definitions/aaa" }
  }
}

{
  "$id": "http://example.com/schema/foo",
  "$schema": "http://json-schema.org/draft-07/schema#",
  "definitions": {
    "aaa": { "const": "example" }
  }
}

Using the method @karenetheridge described for bundling, you would get this ...

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "type": "object",
  "properties": {
    "foo": { "$ref": "#/definitions/aaa" }
  },
  "definitions": {
    "aaa": { "const": "example" }
  }
}

This schema will not work properly because const is not a draft-04 keyword in this context. You would have to include $schema to not lose what draft the embedded schema is using.

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "type": "object",
  "properties": {
    "foo": { "$ref": "#/definitions/aaa" }
  },
  "definitions": {
    "aaa": {
      "$schema": "http://json-schem.org/draft-07/schema#",
      "const": "example"
    }
  }
}

But, you can only use $schema at the root of the schema, so you need an $id to make #/definitions/aaa a root schema.

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "type": "object",
  "properties": {
    "foo": { "$ref": "#/definitions/aaa" }
  },
  "definitions": {
    "aaa": {
      "$id": "???",
      "$schema": "http://json-schem.org/draft-07/schema#",
      "const": "example"
    }
  }
}

But, the referenced schema has no $id for us to put there. Therefore, when embedding schemas with differing drafts, the referenced schema must be addressable with an $id.

Thanks for clarifying @jdesrosiers, crystal clear now.
I'm going to make some changes based on this, other feedback, and discussion from the associated issue!

I've made a few changes based on suggestions.
I still feel like something needs to be said about how $ids of embedded resources can be referenced AS IS.

Ah, it's failing because I need to add an anchor first, then xref target that anchor. I'll fix tomorrow.

I've forced pushed but something has done gone wrong or I've done something wrong with the naming of the branches and I'm not seeing my changes =/

Accidentally deleted the wrong branch in github UI...

I think this is looking good- Any of my remaining comments are more personal style sort of things so however y'all want to resolve them (or leave as is) should be fine.

@karenetheridge After your further review, I think this is good to merge.